Skip to content

Conversation

@wdx04
Copy link

@wdx04 wdx04 commented Oct 2, 2025

Summary of changes

On newer STM32 devices, the DMA channels may be chosen arbitrarily.
This PR allows the use of macros MBED_ANY_GPDMA_MODULE and MBED_ANY_DMA_CHANNEL in DMALinkInfo declarations, so that we can dynamically select unused DMA channels at runtime on the supported STM32 devices.

Impact of changes

The definition of the DMAHandlePointer type has been changed. DMAHandlePointer is now a struct that, in addition to containing a DMA handle pointer, also includes the DMA instance and channel index.

The stm_free_dma_link function now accpets a pointer to DMAHandlePointer.

The spi_s/qspi_s/ospi_s structs now contain dmaHandle members of the DMAHandlePointer type, instead of dmaInitialized members.

A new function is implemented to find an unused DMA channel:

/**
 * @brief Find a free DMA channel for a DMA link with MBED_ANY_DMA_CHANNEL
 *
 * @param dmaLink DMA link instance with MBED_ANY_DMA_CHANNEL
 * @param freeDmaLink DMA link instance with the actual DMA instance and channel indexes
 *
 * @return true if a free DMA channel is found
 * @return false if a free DMA channel is not found
 */
bool stm_find_free_dma_channel(DMALinkInfo const * dmaLink, DMALinkInfo * freeDmaLink);

When the RTOS is present, a mutex object is used for synchronization between threads. New functions stm_init_dma_mutex/stm_lock_dma_mutex/stm_unlock_dma_mutex are introduced to manage the mutex ojbect. stm_init_dma_mutex is called in the mbed_sdk_init function. stm_lock_dma_mutex/stm_unlock_dma_mutex are called in stm_init_dma_link/stm_free_dma_link functions.

Migration actions required

Documentation

None.


Pull request type

[] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[X] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[X] Tests / results supplied as part of this PR

I have tested the QSPI DMA on three boards:

STM32L475E-IOT01A: this board does not have a DMAMUX, so fixed DMA instance and channel indexes are used.
custom STM32H750VB board: the DMA instance is fixed(MDMA), but the DMA channel is dynamically selected.
custom STM32H563VI board: both DMA instance and channel are dynamically selected.

I'll test more boards later.


wdx04 added 2 commits October 2, 2025 09:43
Tested on STM32L475-IOT01A, STM32H563VI(custom), STM32H750VB(custom) boards.
@multiplemonomials
Copy link
Collaborator

OK code looks good, just want to do a test run with the CI test shield. Will do that on my end soon.

One thing I should mention though, we really should create a doc page about how to use the stm_dma_utils code, both from within Mbed and from user code. I think it's a way easier way to use DMA on STM32, but it can be a little hard to figure out if you haven't seen it before, and you have to use it when working with Mbed as it takes over all the DMA interrupts.

@multiplemonomials
Copy link
Collaborator

Hmm, running your branch on NUCLEO_U083RC I get

9: [+462ms][CONN][RXD] ++ MbedOS Error Info ++
9: [+462ms][CONN][RXD] Error Status: 0x80010133 Code: 307 Module: 1
9: [+462ms][CONN][RXD] Error Message: Mutex: 0x0, System is out of memory
9: [+462ms][CONN][RXD] Location: 0x800BB57
9: [+462ms][CONN][RXD] Error Value: 0x0
9: [+462ms][CONN][RXD] Current Thread: <unnamed> Id: 0x0 Entry: 0x8009DED StackSize: 0x0 StackMem: 0x0 SP: 0x20009EF4 
9: [+462ms][CONN][RXD] For more info, visit: https://mbed.com/s/error?error=0x80010133&tgt=NUCLEO_U083RC
9: [+462ms][CONN][RXD] -- MbedOS Error Info --
9: [+462ms][CONN][INF] found KV pair in stream: {{mbed_error;1}}, queued...
9: [+462ms][CONN][INF] found KV pair in stream: {{mbed_error_module;1}}, queued...
9: [+462ms][CONN][INF] found KV pair in stream: {{mbed_error_code;307}}, queued...
9: [+462ms][CONN][INF] found KV pair in stream: {{mbed_error_message;System is out of memory}}, queued...
9: [+462ms][CONN][INF] found KV pair in stream: {{mbed_error_location;0x800bb57}}, queued...
9: [+462ms][CONN][WRN] found KV pair in stream before sync: {{mbed_error;1}}, ignoring...
9: [+462ms][CONN][WRN] found KV pair in stream before sync: {{mbed_error_module;1}}, ignoring...
9: [+462ms][CONN][WRN] found KV pair in stream before sync: {{mbed_error_code;307}}, ignoring...
9: [+462ms][CONN][WRN] found KV pair in stream before sync: {{mbed_error_message;System is out of memory}}, ignoring...
9: [+462ms][CONN][WRN] found KV pair in stream before sync: {{mbed_error_location;0x800bb57}}, ignoring...

Looks like at the time that you are creating the mutex, the RTX memory pools have not been initialized yet so allocation is failing. I think we need to either move the mutex creation later in the init process, or provide a memory block so that it doesn't need to allocate.

@wdx04
Copy link
Author

wdx04 commented Oct 18, 2025

Looks like at the time that you are creating the mutex, the RTX memory pools have not been initialized yet so allocation is failing. I think we need to either move the mutex creation later in the init process, or provide a memory block so that it doesn't need to allocate.

It's a bit strange; normal programs don't encounter this error (RTOS enabled), but the GreenTea test program does report the error. I changed stm_init_dma_mutex to use static memory for dmaMutex's control block and run the GreenTea tests on B-U585I-IOT02A. It seems OK, please test again. Thanks.

@multiplemonomials
Copy link
Collaborator

OK, I was able to run your branch and it passed all DMA SPI basic tests on NUCLEO_H563ZI!

@multiplemonomials multiplemonomials merged commit 4e227b7 into mbed-ce:master Oct 19, 2025
53 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants